[레포트] 서버리스 기반 온디맨드 영상 클립 서비스 구축기

안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 AWS Partner Summit Korea 2022 세션중「서버리스 기반 온디맨드 영상 클립 서비스 구축기」세션을 정리해 봤습니다.

세션 개요

DESCRIPTION

서버리스 방식의 가장 많이 사용하는 것이 이미지 배치 처리이며, 온디멘드 썸네일 서비스에 많이 활용되고 있습니다. 본 세션에서는 동영상 리뷰 서비스인 브이리뷰에서 온디멘드 영상 클립 서비스를 구축한 경험을 공유합니다. 이미지 썸네일 서비스와 같이 언제든지 원하는 크기, 대역폭의 영상을 준실시간으로 인코딩하여 사용자에게 제공할 수 있습니다. AWS Lambda를 기반한 대용량 동영상 인코딩에서 고려해아할 부분을 알아봅니다.

SPEAKERS

강연자

신재현 SW엔지니어, 인덴트코퍼레이션

• 인덴트코퍼레이션에서는 브이리뷰라는 동영상 리뷰 플랫폼을 서비스 하고 있음
• 챗봇을 통해 고객의 동영상 리뷰를 수집하고 쇼핑몰에 리뷰를 노출하는 원스톱 리뷰 플랫폼을 제공 중
• 이러한 리뷰 플랫폼을 통해 소비자 경험을 생산하고 공유하며, 신뢰할 수 있는 커머스 생태계를 구축해나가고 있음

• 이커머스 고객 입장에서는 별도의 운영 비용 없이 한 번의 설치만으로 손쉽게 동영상 리뷰를 수집 할 수 있도록 하고 소비자에게는 브이리뷰만의 특허 챗봇을 통해 동영상 리뷰를 더 쉽게 공유할 수 있도록 하여 신뢰할 수 있는 리뷰를 빠르게 생산해내고 있음
• 마지막으로 이렇게 생성된 실구매자에 대한 영상 리뷰를 잠재 소비자와 직접 연결 시켜주는 리뷰 커머스를 구축하고 있음

• 리뷰 컨텐츠는 텍스트, 이미지, 영상으로 이루어져 있음
• 이 중에서 이미지와 영상 같은 미디어 컨텐츠는 텍스트에 비해 용량이 크다보니 최적화를 제대로 하지 않으면 사용자가 컨텐츠를 보기 위해 오랫동안 기다려야 하는 상황이 발생
• 그러한 상황을 해결하기 위해 일반적으로는 원본 미디어가 생성된 직후 최적화된 미디어를 생성하기 마련
• 하지만 이러한 방식에는 몇 가지 문제가 있음
• 첫 번째로 불필요한 컨텐츠를 생성한다는 점
• 이미지의 경우 화면에 따라 200x200, 500x500 등 다양한 사이즈로 이미지를 리사이징해둠
• 하지만 실제 사용 패턴을 보면 어떤 이미지는 200x200만 소비되고, 어떤 이미지는 500x500만 소비되는 상황이 발생
• 이는 만드는 시점에 어떤 것을 사용할지 모르다 보니 모든 사이즈의 이미지를 생성해야 하기 때문에 발생하는 문제
• 두 번째로 서비스 운영 비용이 서비스의 사용량과 별개로 단순히 데이터의 사이즈에 비례해서 증가한다는 점
• 뉴스 컨텐츠의 경우 매번 새로운 이미지들이 생산되고 소비
• 하지만 10년, 20년이 지난 뉴스는 대체로 소비될 가능성이 매우 낮으면서도 10년, 20년 동안 최적화된 이미지의 저장 비용을 계속 지불하고 있음
• 이는 서비스가 성장하면 성장할수록 서비스의 사용량과 별개로 컨텐츠의 양에 비례하여 비용이 증가된다는 점
• 마지막으로 서비스의 유연성이 매우 떨어짐
• 새로운 최적화된 이미지를 추가하려면 이때까지 저장된 모든 이미지에 대해서도 일괄적으로 작업이 진행 돼야 함
• 이는 자연스럽게 시간이 지나면 지날수록 새롭고 다양한 포맷을 추가하는 것이 매우 어려워지고 사용자 경험에도 안 좋은 영향을 미치게 됨

• 첫 번째로 사용자가 요청하는 시점에 컨텐츠를 생성하기에 꼭 필요한 컨텐츠만 생성 할 수 있음
• 두 번째로 고정비인 저장 비용 대신 사용량에 비례한 컴퓨팅 파워를 기준으로 비용이 청구
• 이를 통해 실제 사용량에 비례한 비용 효율적인 서비스를 구축 할 수 있음
• 마지막으로 새로운 포멧을 추가하더라도 그 즉시 적용이 가능하기 때문에 새로운 포멧을 추가하는데 부담이 전혀 없음
• 이는 최적화된 컨텐츠를 점진적으로 개선해 나갈 수 있는 환경을 제공하며 사용자에게 매일 매일 좀 더 나은 서비스를 제공 할 수 있도록 발판을 마련 할 수 있음

• 사전에 컨텐츠를 만들어 두지 않고, 사용자가 요청하는 시점에 컨텐츠를 만들다 보니 캐싱 되지 않는 첫 번째 요청의 경우 기존보다 응답 시간이 늦을 수 밖에 없음
• 아무리 좋은 아키텍처의 서비스라도 어떤 사람은 경우에 따라 이미지를 보는데 5초 이상의 시간이 걸리게 되면 안 되기 때문임
• 그래서 응답 속도는 온디맨드 서비스에서 굉장히 중요한 지표 중 하나임
• 또한 일반적으로 미디어 컨텐츠를 최적화 하는 데는 순간적으로 많은 컴퓨팅 파워가 필요
• 특히나 마케팅이나 여러 이벤트들에 의해 갑자기 트래픽이 폭증하는 이커머스 서비스 특성상 고성능 인스턴스를 안정적으로 오토스케일링 할 수 있도록 인프라, 소프트웨어적으로 많은 대비를 해야 함
• 이는 사전에 컨텐츠를 만드는 것보다 운영 난이도가 대폭 올라가게 되는 원인이 됨

• 먼저 서버리스 서비스들은 서버를 관리할 필요가 없기 때문에 서버를 관리할 시간에 오직 서비스 자체의 가치를 계산하는 데만 집중 할 수 있음
• 개인적으로 항상 리소스는 부족하고 시간이 금인 스타트업에서는 이 부분이 정말 중요한 장점이라고 생각
• 두 번째로 서버리스를 통해 손쉽게 높은 가용성을 확보할 수 있음
• 앞서 온디맨드 서비스의 특성상 높은 컴퓨팅 파워를 단시간에 많이 필요로 할 수 있다고 설명했음
• 서버리스 서비스들은 모두 높은 가용성이 이미 확보되어 있어 트래픽이 몰리더라도 서비스는 안정적으로 스케일업 됨
• 세 번째로 각 서버리스 서비스의 청구 방식을 잘 활용하면 굉장히 비용 효율적으로 서비스를 구축할 수 있음
• 가령 EC2 인스턴스는 S3에서 데이터를 다운을 받을 때, 데이터 전송 비용이 나가게 됨
• 하지만 람다의 경우 주요 서버리스 서비스 간의 데이터 전송 비용이 무료이기에 아무리 큰 데이터라 하더라도 추가적인 데이터 전송 비용이 나가지 않음
• 또한 CloudFront의 경우 캐싱된 데이터의 저장 비용이 아닌 전송 비용에 대해서만 비용을 청구함
• 이를 활용하면 한번 캐싱된 컨텐츠에 대해서는 캐시가 무효화되기 전까지 매번 이미지를 생성하지 않으면서도 별도의 저장 비용을 지불하지 않아도 됨

썸네일 서비스 구축 사례

• 먼저 브이리뷰에서 이미지가 생성되고 소비되는 과정을 설명
• 리뷰 작성자는 챗봇을 통해 이미지를 업로드 함. 서버에서는 이렇게 업로드된 이미지를 S3에 저장하게 됨
• 이후 소비자가 상품 상세 페이지에 접속하게 되면 리뷰 위젯은 섬네일 서비스에 최적화된 사이즈의 이미지를 요청함
• 요청이 제일 먼저 CloudFront로 도착하면 CloudFront에서는 제일 먼저 파일이 캐싱 되어 있는지 확인 함
• 만약 캐시된 파일이 없다면 API Gateway를 통해 람다에 섬네일 이미지 생성을 요청
• 람다는 원본 이미지를 다운로드 받아 섬네일 이미지를 생성하고 캐시를 태우게 됨
• 이렇게 브이리뷰에서는 CloudFront, API Gateway, 람다 만을 활용하여 비용 효율적이면서 유지보수가 필요 없는 서비스를 손쉽게 구축하고 운영하고 있음
• 참고로 리사이징 할 때 응답속도는 대체로 100 ~ 300ms 안팎이기 때문에 사용자가 큰 체감을 하지 못함
• 이후 캐싱된 이미지의 응답 속도는 대체로 20 ~ 30ms임

Amazon S3 Object Lambda

• S3 Object Lambda는 클라이언트가 S3에 오브젝트를 가져오는 요청을 하면 Lambda를 실행하여 새로운 파일을 제공할 수 있는 서비스
• 첫 번째로 기존에 S3를 사용하는 어플리케이션에서는 별도의 코드 수정 없이 S3 Object Lambda를 적용할 수 있다는 점
• 그리고 두 번째로 섬네일 서비스와 같이 별도의 API Gateway를 구성하지 않아도 되고 비슷한 역할을 하는 Lambda@edge나 CloudFront function보다 저렴하다는 것
• 마지막으로 API Gateway와 달리 응답 크기에 대한 제한이 없어 아무리 큰 영상이라도 온디맨드로 생성 가능하다는 점이 매우 만족스러움

• 기존에 S3 SDK는 모두 access point를 통해 접근이 가능하기 때문에 어플리케이션 코드를 수정 없이 지원이 가능했음
• 문제는 CloudFront에서 S3 콘텐츠를 직접 서빙할 때는 S3 access point 를 지원하지 않는다는 점
• 또한 S3 Object Lambda는 한 번에 하나의 파일만 요청하기 때문에 HLS처럼 하나의 영상에 대해 여러 파일이 생성되야 하는 경우에는 활용을 전혀 할 수 없다는 점
• 이 두가지는 서비스 구축이 아예 불가능할 정도로 설계적 결함이었고, 결국, 이 아키텍처는 포기하게 됨

• 하나의 HLS 영상은 마스터 플레이리스트와 미디어 플레이리스트
• 그리고 영상 세그먼트 파일들로 구성이 되어 있음
• HLS 플레이어에서는 마스터 플레이리스트를 다운로드 받아 영상이 몇 개의 품질로 제공되어 있는지 파악함
• 이후 네트워크 환경에 따라 최적의 대역폭을 가진 미디어 플레이리스트를 다운로드 받음
• 마지막으로 미디어 플레이리스트에 있는 세그먼트를 영상을 재생시간에 따라 점진적으로 다운로드 받아 재생하는 방식으로 작동이 됨

• HLS는 이러한 구조를 통해 네트워크 환경이 변하더라도 자동으로 최적화된 품질의 영상을 끊김 없이 재생함
• 또한 HLS는 장애 복구 기능이 내장되어 있어서 일시적으로 다운로드가 불가능하더라도 자동으로 후속 파일 다운로드를 재시도하여 네트워크가 불안정한 환경에서도 안정적으로 영상을 스트리밍 할 수 있음
• 마지막으로 두 개의 플레이리스트와 첫 번째 영상 세그먼트만 있다면 영상이 모두 트랜스코딩 되기 전에 짧은 지연 시간만으로 영상을 재생할 수 있음

영상 트랜스코딩 서비스

• 가장 먼저 HLS에서 영상을 재생하기 위해선 최소 3개의 파일만 다운로드 받으면 되는 점을 착안
• 즉, 영상이 아무리 크고 트랜스코딩 하는 데 오랜 시간이 걸리더라도 3개의 파일만 있으면 재생을 시작할 수 있고 무엇보다 그중 2개의 플레이리스트 파일은 단순 텍스트 파일이기 때문에 생성하는데 시간이 거의 소모되지 않는 점도 적극적으로 활용했음

• 최종적인 아키텍처는 다음과 같음
• 제일 먼저 플레이어에서 마스터 플레이리스트를 요청하면 Lambda는 트랜스 코딩 여부를 확인하고 만약 트랜스코딩된 파일이 없다면 SQS에 트랜스코딩 요청을 한 뒤에 마스터 플레이리스트 파일을 생성하여 캐싱에 태움
• 이후 비동기적으로 SQS에 트리거를 받은 Lambda가 각 품질별 영상을 병렬적으로 트랜스코딩 하고 파일이 생성되자마자 바로 S3에 업로드되게 했음
• 마지막으로 플레이어에서는 마스터 플레이리스트를 기준으로 원하는 품질의 미디어 플레이리스트를 다운받은 뒤에 조각난 영상 파일을 점진적으로 다운로드 받아재생함으로써 아무리 큰 영상이라도 사용자가 원하는 형태의 최적화된 영상을 온디맨드로 생성 가능한 트랜스코딩 서비스를 구축할 수 있었음

참고

본 블로그에서 사용한 이미지는 AWS Summit Korea에서 제공된 발표자료와 영상을 사용했습니다.